With the use of the Internet becoming commonplace, online purchases have also become widespread. In a typical transaction, a user makes a purchase from a merchant using a financial vehicle. The user can be a person or a nonperson business entity, agency or organization. The merchant can be an established product seller or reseller, a broker, a service provider or an individual or business entity making a single or a few transactions, such as an auction participant. The financial vehicle can be a credit card, debit card, electronic credit, digital cash, person-to-person payment or the like. As an example, an individual might use a credit card to purchase a book from an online bookstore.
Since the transaction is online, it is often more precise to refer to a user computer system, a merchant computer system and an issuer computer system. Thus, for a transaction to take place, the user computer system connects to the merchant computer system and interacts, then the user computer system and/or the merchant computer system connects to the issuer computer system and interacts, with the merchant computer system typically interacting with the issuer computer system, if at all, through an acquirer computer system that in turn interacts with the issuer computer system via a payment network, such as the VISANET(™) network operated by Visa International. In card systems, “issuer” is the term typically used to refer to the entity that issues a card (or a card number) to a user for the purpose of making purchases upon presentation of the card or the card number. Typically the entity is a bank or other financial institution or an agent of a bank or financial institution. The term “acquirer” refers to the entity that accepts the transaction details from the merchant and effects a transfer of funds from the issuer to the acquirer on behalf of the merchant. In some cases, the issuer and acquirer might be the same entity. The systems might be large computer processing systems, personal computers, handheld devices, wireless devices, cellular telephones with data capability, or other computing devices.
One increasingly common method of connection and interaction is via the Internet, a global internetwork of networks in common use today. Of course, as the Internet changes, the resulting networks might also carry such traffic. One concern with traffic over the Internet is that data can be intercepted and parties to a transaction can be impersonated. In addition, since a merchant can easily set up an online business, someone with the intent to defraud cardholders and issuers might set up a business, engage in transactions and then use the card numbers provided by users for unauthorized transactions. Another concern with online transactions is that an unauthorized system might pose as a user system and effect a transaction to the benefit of the operator of the unauthorized system.
One-Time Cards
One approach to preventing, or at least reducing, credit card fraud is to issue one-time card numbers to users. With this approach, each user might be assigned a permanent card number, but that permanent card number is not given to the merchant. Instead, a one-time card number is generated and given to the merchant. Since the one-time card number can only be used for that one transaction, that prevents unauthorized persons or entities from initiating another, unauthorized transaction using that number. The user can generate the one-time number or the issuer can generate it and provide it to the user for use with the merchant. The one-time number (“OTN”) might be generated as a function of details of the transaction, such as the permanent card number, the transaction amount, transaction date, time, merchant identifier, etc. If the OTN is a function of the permanent card number, preferably the function is a one-way function so that the permanent card number cannot be determined from just the OTN. In some designs, a permanent card number might be determinable with enough time and computing power, but it should be understood that a system that was breakable but required enough time or computing power to eliminate the usefulness or economic benefit of the break is effectively equivalent to an unbreakable system. Of course, a “permanent” card number need not be permanent for all time. Thus, it should be understood that, herein, “permanent card number” refers to a number such as a credit card number assigned by an issuer to its customer, the user, for use over an indefinite period of time for an indefinite number of transactions. One example of a permanent card number is a credit card number assigned to a user that is embossed on a card held by the user.
Where the permanent card number is used instead of OTNs, there is an opportunity for a merchant to cheat (e.g., by charging the user repeatedly for a single transaction) and for an interloper to cheat (e.g., by eavesdropping on the user-merchant interaction, gaining the permanent card number and using that in transactions with that merchant or other merchants). When a user wants to participate in a transaction with a merchant, the issuer or the user generates the OTN, so the permanent card number need never be sent to the merchant. In some arrangements, the OTNs are such that they can be used in the same payment networks as are used for transactions using the permanent credit card numbers. Thus, in some cases, the merchant and other handlers of the OTNs will not be able to distinguish between a OTN and a permanent card number. However, in some implementations, mechanisms exist in appropriate places in the payment network to distinguish an OTN from a permanent card number.
Several schemes have been proposed in the literature for generating and handling OTNs, but typically such schemes require too much runtime effort (leading to transaction delays for the users), do not scale well, or both.
One scheme is the Microsoft online commerce system scheme. With that approach there are three phases: 1) a registration phase, 2) a transaction phase, and 3) a payment authorization phase. During the registration phase, the issuer supplies the user (the issuer's customer) with an account number, such as the permanent card number as described above, and a private key. The user system maintains those data as secrets of the user. The issuer also supplies the user with a software module that controls OTN generation. The issuer maintains a record of the user's account number and corresponding private key, typically in a user database.
Once registered, the user can effect a transaction. The transaction phase occurs when the user initiates an online transaction. To do this, the user invokes the software module supplied by the issuer and the module prompts for a password or performs some other authentication of the user. Upon entering the correct password or otherwise verifying identity, the user system can then access the secret information (including the private key). Subsequently, the software module generates a OTN, which in this case is a credit card number usable only once. The number is a function of the user's account number, the user's private key, the time of transaction, transaction amount, merchant ID, and possibly other data.
As part of the transaction process, the user sends the OTN to the merchant as a proxy for the user's account number. The OTN in this scheme is such that it appears to the merchant to be a valid credit card number. This feature allows the merchant to use existing payment networks to process the transaction. Of course, since the number is valid for only one transaction, if the number is presented again to the issuer, either by the merchant or an interloper, the issuer will reject the transaction and no funds will change hands.
In this specific scheme, the OTN 10 is a 16-digit number, like other credit and debit card numbers, and is divided into fields as shown in FIG. 1. As shown, the first field 12 is one digit indicative of the payment system used by the issuer with that user. By way of example, “3” indicates one payment system “4” indicates another payment system, “5” indicates yet another, “6” indicates another, etc. The second field 14 is four to six digits that are associated with the particular issuer. The third field 16 is four digits that are associated with the particular user. The first three fields (9 to 11 digits) do not change from transaction to transaction. The last digit 20 is a checksum value dependent on the first fifteen digits, so there are only four to six digits that can change independently from transaction to transaction. Those four to six digits are referred to as a “Message Authentication Code” or “MAC” 18. The MAC can be a cryptographic hash of transaction parameters, such as those mentioned above.
During the payment authorization phase, the merchant submits an authorization request to the issuer over an existing payment network. The request includes a transaction number and other transaction-specific data. If the issuer identifies the transaction number supplied by the merchant as a OTN, the issuer relates that OTN to a user using the third (and possibly the second and first) fields of the OTN. The issuer then computes a MAC as a function of the known customer specific data, transaction specific data and the private key of that user. The hash function used would be the same one used by the user to generate the MAC in the OTN provided to the merchant. If this issuer-generated MAC matches the one in the OTN by the merchant, then the issuer accepts the authorization request and processes the transaction internally using the user's permanent card number or other user identifier. Replies to the merchant would use the OTN rather than the user's permanent card number.
A more general description of such an online transaction is shown in the swim diagram of FIG. 2, which illustrates interactions between a user system, a merchant system and an issuer system. The steps of the swim diagram are labeled “S1”, “S2”, “S3”, etc. As shown there, the user interacts with the merchant to define parameters of the transaction, such as what products or services would be purchased, quantities, and the like (step S1). The user system generates a one-time number 22 from user and transaction data and sends that one-time number to the merchant system (S2). The merchant system then uses that number to request the authorization (S3) and to begin the payment process with the issuer. The one-time number encodes for the user identification, as well as being a function of transaction details. Once the issuer receives a request (S4) from the merchant, the issuer system can verify the validity of the OTN relative to the transaction details 24 used to generate that OTN (S5). Since the OTN encodes for the user ID, the issuer can determine which user is party to the transaction. If the one-time number encodes for a valid user ID and correctly encodes for the selected transaction details, and sufficient funds are available to the identified user, then the issuer responds to the merchant's authorization request with an approval (S6). The merchant then proceeds with the transaction and notifies the user as needed (S7).
The above scheme does not scale well, as only 10,000 distinct customers of a given issuer can be supported since only four digits are usable for customer identification. The above scheme also has a problem in that the probability of fraud is not greatly reduced. Since only four to six digits are allocated for the MAC, a dishonest merchant or interloper can easily generate all the ten thousand to one million possible MACs and submit fraudulent transactions and some of them will be accepted. A merchant that processes one legitimate transaction can use the received OTN as a starting point to generate an unauthorized transaction and submit the transaction to an issuer. On average, if a merchant automatically generates a large number of such unauthorized transactions, as many as one per 10,000 unauthorized transactions will succeed.
Other OTN card schemes provide more protection against fraud, such as the issuer-generated numbers used by some companies, such as Orbiscom. FIG. 3 is a swim diagram of such a scheme. With this scheme, the OrNs do not necessarily match fields with the user's permanent number, which allows for more variability in the MAC. As with the Microsoft scheme, each user system includes software provided to handle OTN generation. In the issuer-generated approach, however, the user authenticates with the issuer (S10, S11) and the issuer generates the OTN (S12). The OTN may encode for other capabilities, such as a transaction value or time limit, or for limitation to a specific merchant.
Once the user system obtains the OTN (S13), the user sends the OTN to the merchant along with other transaction details (S14). The merchant processes the transaction in the normal way (S15) using the desired payment network and forwards the OTN and other details to the merchant's acquirer (i.e., sends a message to a payment network). The acquirer then sends the OTN and transaction amount to the issuer, directly or indirectly (S16). The issuer then associates the OTN with the appropriate customer and proceeds with the transaction (S17). After processing the request, the issuer either approves or declines the transaction and sends the response to the acquirer (S18). The acquirer forwards the response to the merchant and the merchant notifies the customer as to whether the transaction has been approved or declined (S19).
In specific embodiments, the issuer issues an OTN wherein the first five digits identify the issuer and ten digits can independently vary between OTNs for any given customer. Since the issuer generates the OTN and presumably stores the OTN in association with the user that requested the OTN, the issuer can reassociate that OTN with that customer when the OTN is received from the merchant without having to determine the customer from the contents of the OTN. This leaves more digits of the OTN available for the MAC, which in turn allows a given numbering scheme (e.g., 16 digit decimal numbers with one digit being a checksum) to support more distinct users and lower the probability of valid numbers being generated without full knowledge of the user data.
While the issuer-generated scheme is more scalable and deflects more fraud attempts, it has its own difficulties. Since the issuer generates the OTN, the user has to wait until the OTN is returned from the issuer before proceeding with a transaction and such a delay might not be acceptable. If the issuer system is tied up or is not immediately responsive, the user may choose to abandon the transaction altogether.
Online Authentication
Online transactions often expect parties to authenticate themselves to other parties. For example, a user system might be expected to authenticate itself to an issuer system before the issuer system would accept an OTN and transaction from the user system. Generally, authentication involves a client proving to a server that the client has the authority it claims to have, usually by responding to a challenge that indicates that the client has information that only an authorized party is supposed to have. Such information might be passwords, passwords with one-way functions, passwords with salts, SKEY data, digital signatures, etc. In a typical operation, the client requests authorization, the server responds with a challenge, the client responds with a response to the challenge and the server responds with either approval or denial of the authentication based on whether the response to the challenge was correct.
In a specific implementation, the client has a private key and a matching public key. The client sends an authorization request to the server and the server responds with a challenge, such as a random string. The client then encrypts or signs the challenge with the client's private key and sends the result to the server. The server uses the public key of the client to decrypt or verify the client's message. The server can access the public key of the client in one of many ways: the public key could be in the database of the server, or the public key could be sent by the client to the server (as a certificate for instance), etc. If the decrypted message is the same as the challenge sent by the server or the signature is verified, the client is deemed authenticated. If not, the client is denied authentication.
This typical authentication process involves two round-trips, resulting in delays to the client and possible stalls if the client-server connection stalls. In many cases, time spent at a transaction determines whether the user will complete the transaction, so it is important that the user not have to wait for the transaction to proceed.